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(57) Abstract: A system for managing risk transactions includes an Internet web server in communication with risk customers and 
^5 insurers. The web server accepts requests for quotes from customers and markets them to insurers. The insurers compete to offer the 
^ most favorable quote to the customer taking into consideration various factors, including premiums and service. The competition 
^ can include online negotiation sessions between the parties. The customer can be advised online by an advisor. 
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SYSTEM FOR MANAGING RISK TRANSACTIONS 

1 0 RELATED APPLICATION 

This application claims the benefit of U.S. Provisional Application No. 
60/162,846, filed November 1, 1999, the entire teachings of which are incorporated 
herein by reference. 

15 BACKGROUND 

Risk transfers are examples of non-commodity transactions. Typically, a 
manual process occurs for each transaction. A customer generally employs an 
insurance agent or a broker to obtain insurance coverage. The customer typically tells 
the agent/broker what risk needs insuring. The agent/broker selects a primary insurer 

20 or a re-insurer and then exchanges information with the insurers and re-insurers to 
obtain a policy. The selection of insurers is largely based on the agent/brokers past 
dealings with the insurers. Paper contracts, policies and other documents are 
exchanged between the parties to complete the legal relationships. 

In the prior art, risk managers and insurers have little direct access to 

25 information, in real-time or otherwise. Instead, a convoluted distribution model is 
employed. Much of that distribution is the flow of paper-based information. The 
result is that the property casualty insurance industry carries a large expense burden, 
with about 37 cents of every premium dollar going toward administration and 
distribution. 

30 

SUMMARY 

A system for managing a risk transaction can handle each functional phase of 
a risk transaction. A database can maintain data provided by parties to the 
transaction, including data specific to a particular risk transaction. The system can 
35 operate to compress the supply chain and to integrate multiple risk products into a 
manageable platform. 
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In accordance with a particular embodiment, a system for managing risk 
transactions can include a database having stored therein risk data from a plurality of 
customers and a plurality of risk bearers. The system can also include a first interface 
for exchanging risk data with a customer and a second interface for exchanging risk 
data with a risk bearer. A third interface can be used to exchange risk data with an 
advisor representing the customer. A data interface can also couple the database to an 
external data collector, such as Edgar. The system can also include an online 
collaboration facility usable by the parties, including a customer and a risk bearer. 

Each party can be represented by a plurality of authorized users. Each user 
can have its own interface to the system. In addition, each user can be assigned a 
respective access right or privilege selected from a plurality of access rights available 
to users on the system. 

The database can be coupled to a server computer on a computer network. 
The stored risk data can represent various aspects of a risk transaction, including a 
1 5 risk profile from a customer, a request for quote from a customer, an insurance quote 
from a risk bearer, and an insurance policy between a customer and a risk bearer. 
The risk data can also represent a facultative reinsurance agreement between a 
plurality of risk bearers and a customer. The risk data can also include a dynamic 
product definition and dynamic pricing of a risk product 
20 In particular, the system can include a risk exchange platform in 

communication with customers and a risk bearing market The risk exchange 
platform can also be in communication with advisors for assisting the customers. 
Real-time support can also be available to the customers, advisors, and risk bearers. 
In a specific embodiment the risk exchange is an Internet-based web server 
25 accessible by a plurality of client parties. 

A customer interface to the risk exchange platform facilitates the creation of a 
request for quote for transferring at least a portion of a risk from the customer to the 
risk market The customer interface can further facilitate the building of a risk profile. 
The customer interface can also access a computer-based work environment to 
30 facilitate collaboration between the customer and another party. The other party can 
be an advisor assisting the customer, a party representing a risk bearer, such as an 
employee of insurer, or a support facility of the risk exchange platform. 

The customer interface can further facilitate receiving a quote from a risk 
bearer. In response to that quote, the customer interface can further facilitate 
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negotiation between the customer and the risk bearer. For the negotiation, the 
customer interface can access a computer-based work environment. Through the 
customer interface, the customer can integrally manage a plurality of risk products for 
the customer. 

5 

BRIEF DESCRIPTION OF THE DRAWINGS 

The foregoing and other objects, features and advantages of the invention will 
be apparent from the following more particular description of particular embodiments 
of a system for managing risk transactions, as illustrated in the accompanying 
1 0 drawings in which like reference characters refer to the same parts throughout the 
different views. The drawings are not necessarily to scale, emphasis instead being 
placed upon illustrating the principles of the invention. 

FIG. 1 is a block diagram of a computer-based risk management system. 

FIG. 2 is a block diagram of a particular risk management system. 
15 FIG. 3 is a flowchart of the lifecycle of a risk transfer in the system of FIG. 2. 

FIG. 4 is a block diagram of software components in the risk exchange 
platform of FIG. 2. 

FIGs. 5A-5C when combined are a schematic diagram of a display screen for 
navigating the Risk Profiler component of FIG. 4. 
20 FIG. 6 is a flowchart of a process for preparing a Request For Quote. 

FIG. 7 is a schematic block diagram illustrating interactions for the risk 
profiling, risk assessment, and program design steps of FIG. 3. 

FIG. 8 is a schematic block diagram illustrating interactions for the complete 
and send RFQ steps of FIG. 3. 
25 FIG. 9 is a schematic block diagram illustrating the collaboration and 

negotiation steps of FIG. 3. 

FIG. 10 is a schematic block diagram illustrating the bind, issue, and store 
steps of FIG. 3. 

FIG. 11 is a schematic block diagram illustrating interactions for issuing and 
30 distributing a certificate. 

FIG. 12 is a schematic block diagram illustrating interactions for generating 
automobile identification cards. 

FIG. 13 is a schematic block diagram illustrating interactions for policy 
management functions. 
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FIG. 14 is a schematic block diagram illustrating interactions for a claim of 
first report of loss. 

FIG. 1 5 is a schematic block diagram illustrating interactions for loss run 
reporting. 

5 FIG. 1 6 is a schematic block diagram illustrating interactions in a lead and 

follow model for facultative reinsurance. 

FIG. 17 is a schematic block diagram illustrating interactions in a subscription 
model for facultative reinsurance. 

1 0 DETAILED DESCRIPTION 

Embodiments of the invention include a comprehensive system to solve the 
problems of inefficiency and cost in the insurance and risk transfer industry. A 
particular embodiment of a risk management system includes a transparent platform 
for transferring risk. Parties can obtain real-time access to risk data and risk analytics. 
In particular, an Internet-based business-to-business marketplace offers competitive 
bidding and direct access to top-tier risk-bearing markets (insurers, re-insurers, 
alternative risk, and capital markets). In addition, an online risk management ' 
application simplifies and streamlines the administration of commercial insurance and 
enterprise risk management programs. 

FIG. 1 is a block diagram of a computer-based risk management system. The 
system includes a risk exchange platform 1 0 in communication with a plurality of 
customers 11-1, 11-2, ... , H- N> a plurality of advisors 15-1, 15-2, ... , 15-M,anda 
plurality of insurers 19-1, 19-2, .... 19-P. The risk exchange platform lOstoresand 
manages risk and insurance data for each transaction and facilitates risk transactions. 
25 The system can have a client-server architecture on a computer network 

nG. 2 is a block diagram of a particular risk management system. At the core 
is the risk exchange platform 10 embodied as an Internet web server. More 
specifically, the risk exchange platform 10 employs a marketplace engine using 
Application Service Provider (ASP) technology. 

The risk exchange platform 10 communicates with a Risk Manager customer 
1 1 that represents an entity seeking insurance policies, an Advisor 1 5 that assists the 
Risk Manager 1 1 during the process of creating a request for an insurance policy, and 
an Underwriter 19 that represents an entity that provides insurance policies. The Risk 
Manager 1 1 , Advisor 1 5, and Underwriter 1 9 can be operating on remote client 
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computers communicating with the risk exchange platform 10 over the Internet. Also 
shown is an exchange system operation support facility 12 that provides customer 
support for the Risk Managers 1 1 , Advisors 1 5 and Underwriters 1 9. The support 
facility can be on a local area network with the platform 10 or remotely located and 
5 communicating over the Internet. The support facility 1 2 interacts with the other 
users on a real-time basis within the system. In addition, third parties 1 8 can perform 
auditing of the system or provide data via an Internet connection. 

FIG. 3 is a flowchart of the lifecycle of a risk transfer in the system of FIG. 2. 
It is assumed that the parties have already registered with the system. Initially, the 

10 Risk Manager 1 1 sets up a company on the system, enters and uploads risk data. 

At step 50, the Risk Manager 1 1 optionally works with an Advisor 15 to create 
a risk profile. Then, at step 52, the risk is assessed and a program is designed to 
submit to the system as a request for quotation. At this point, there may be offline 
communication between the Risk Manager 1 1 and the support facility 12 to ensure 

1 5 that the correct data has been entered and supplemental data from third party sources 

18 is tied to the user. 

At step 54, the Risk Manager 1 1 and Advisor 1 5 create the Request for Quote 
(RFQ) that is in turn sent to the Underwriters 19: Because the majority of the 
information needed to create the RFQ was entered during the previous steps, this step 

20 consists mainly of specifying the desired coverage, and selecting underwriters. The 
platform 10 creates the list of possible Underwriters 19 by matching the criteria of the 
RFQ with the risk preferences set up by the Underwriters 1 9. Once the Risk 
Manager 11 has selected Underwriters 19, the platform sends the structured and 
unstructured data to them. 

25 Once the RFQ has been submitted, the Underwriter 19 decides, at step 56, to 

either decline the risk or begin the quoting process. If the Underwriter declines the 
risk, then processing jumps to step 64. If the Underwriter decides to continue, he 
places the RFQ into the "In Progress" status at step 58, and determines what 
additional information is needed. 

30 During this period of time, the Risk Manager 1 1 , Advisor 1 5, and Underwriter 

19 can collaborate at step 60, including one-to-one communication and collaboration 
using workrooms. Some of this communication may occur offline, via phone, fax or 
direct email. 
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Once the Underwriter 19 has collected sufficient data, he again decides to 
quote or decline the risk at step 62. If the Underwriter 1 9 declines the risk, processing 
jumps to step 64. Otherwise processing.continues to step 66. 

AUtep 64, the Underwriter 19 specifies a reason for declining the risk. 
5 Processing then exits. 

tf&eUnd ™ 19de ^tooffera q uoteontherisk,the q uotei S sentto 
4eR ls kMana g er 11 at step 66 and another period of collaboration occurs, thisthne 
focusmg on negotiation of the tenns and conditions of the offer. Again, some of this 
communication may occur offline. 
10 ^ Continuing to step 70, the Risk Manager 1 1 decides which quote to accept 
Once accepted, the Underwriter 19 binds coverage at step 72. At step 74, the Risk 
Manager 1 1, Advisor 1 5, and Underwriter 1 9 negotiate policy wording. Ultimately 
the policy is issued at step 76. The data is then stored on the platform at step 78 for' 
reference in future RFQs and for use in managing the policy. 

FIG. 4 is a block diagram of software components in the risk exchange 
Platform of FIG. 2. As shown, the risk exchange platform 10 includes a Risk Profiler 
component 11 0 and a News Portal component 1 90 accessible by the Risk Managers 
11 and the Advisors 15. An Exchange component 120, a Communication Link 
component 130, a Research Tools component 150, an Adnunistrauon component 160 
aSup P ortcomponentl70,and an Account Information component 1 80 are accesrible' 
bytheR I skManagersl,, m eAdvisorsl5,andmeUnderwritersl9. Inaddition a 
Rtsk Assistant component 140 is accessible by the Risk Managers 1 1, an Advisor 
Ass,stant component 143 is accessible by the Advisors 15, and an Underwriter 
Assistant component 146 is accessible by the Underwriters 19. The Advisors 15 can 
also access a Client Information component 185. Each of these components will be 
described in detail below. 



15 



20 



25 



Risk Profiler Component 

^^^ercomponentllOaUowsRiskManagetslltocomplete 
^formation for their co mpany and the coverages ^ ^ ^ 

obtaming. A Risk Manager 1 1 can use the Risk Profiler component 110 to maintain 
^nskdataandcreateaRFQforsubmissiontotheexchange. Through the Risk 
Profiler component 1 1 0, the Risk Manager 1 1 can view the outstanding RFQs for the 
company. The Risk Manager 1 1 can also view the company's profile and its risk 
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management profile. The Risk Manager 1 1 can use the Risk Profiler component 1 10 
to complete exposure schedules and loss profiles. 

The Risk Manager 1 1 uses a menu display to navigate through the Risk 
Profiler component 1 10. Clicking on a command takes the user to an appropriate 
5 screen. Through this process, the user can navigate the Risk Profiler 1 1 0 by RFQ or 
by each element of the Risk Profiler 110. All data regarding forms is delivered on the 
Standard Industry Codes (SIC) that are specified in the corporate hierarchy and 
general information screens. Fields within a form can have numerous dependencies. 
Some fields are common to all industry types and appear always, some are specific to 
10 the industry type, and some are dependent on previous responses in the coverage 
specification or coverage questionnaire. 

FIGs. 5A-5C when combined are a schematic diagram of a display screen for 
navigating the Risk Profiler component of FIG. 4. The screen shows folders for each 
. of the lines of coverage. Expanding the folder shows "company profile", "risk 
1 5 management profile", "coverage profile", "exposure profile", and "loss profile". A 
button is selected to create a RFQ. 

FIG. 6 is a flowchart of a process for preparing a Request For Quote. This is 
the start of the process to create a bid package. It is accessed from the Risk Profiler 
screen off the customer desktop, by clicking the "Create a RFQ" button. 
20 The process begins, at step 205, where the customer selects the coverage that 

it wishes to bid into the market The selection is made from a list of available 
coverage forms within the exchange at that time, plus free-form RFQs. The customer 
can also be given the option of selecting from existing coverages in the policy 
management section of the site. One example would be renewing an existing 
25 coverage. That action automatically loads the coverage profile for that existing policy 
to be bid into the market. 

At step 210, the customer is asked to specify if this is a primary policy or an 
excess policy (i.e. there are underlying policies). Once a coverage is selected, the 
system generates a unique RFQ number to attach to the bid package that is being 
30 developed. It also assembles a unique combination of risk data that is required to be in 
the RFQ package. The newly initiated RFQ shows as being in progress in the 
customer desktop. 

There are four sections of the RFQ that will be completed to constitute the bid 
package. Each is contained in separate folders: 
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■ A coverage profile, which includes the coverage specifications (what the 
customer wants to buy), and where appropriate the underlying coverages for 
the policy. 

■ A company profile, which details general information about the Company. 
5 The company profile information accompanies every RFQ bid package. 

■ An exposure profile, which includes the underwriting data for the company 
as well as information on the risk control protections in place to manage that 
particular risk. The exposure profile information is unique to the particular 
RFQ. But there can be a high degree of overlap between different RFQs. 

10 The exposure profile data writes to a central database that is populated from 

the different RFQs. Where the exposure profile information already exists, 
the forms can be pre-populated. 

■ A loss Profile, which contains summary loss information, large loss 
information above an amount specified by the customer ($50,000/$ 100,000, 

15 etc.) and loss runs, either supplied electronically or scanned. 

From the select coverage form, the customer is taken to a build coverage profile 



screen. 



20 



25 



30 



Once the customer has selected a coverage to bid and a unique RFQ number 
has been assigned to it, subsequent profile forms appear with an appoint advisor 
button, allowing the customer to appoint an advisor to work with them at any point 
during the RFQ development process. 

A new screen is displayed for the Risk Manager to initiate an RFQ for a 
particular line of coverage. The Risk Manager 1 1 can indicate which line of coverage 
to assemble the RFQ for, by checking a line of coverage. If the Risk Manager 1 1 
wishes to bid multiple lines of coverage together, a multiple line option can be 
selected, which allows the Risk Manager 1 1 to select more than one individual line of 
coverage for the RFQ. The Risk Manager 1 1 can also appoint an advisor to help with 
the RFQ, from the list of advisors that have been appoint to the account 

Another screen allows the customer to select the underlying coverages for the 
policy being bid. This should essentially direct the customer to the policy 
management section of the site to select these underlying coverages. If the policy is 
not listed, the person is directed to add the coverage to the policy management 



section. 
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If the coverage is for an excess placement, processing jumps to step 215. At 
step 2 1 5, a list of underlying policies are displayed. If an underlying policy is not 
displayed, step 220, then the Risk Manager 1 1 can add that policy at step 225. 
Inclusion of certain underlying coverages may require completion of additional 
5 exposure profile and risk management profile information. This additional 

information, if any, is displayed in the RFQ folder once the underlying coverage(s) is 
selected. At step 230, the Risk Manager 1 1 selects the appropriate underlying policy. 
Processing returns to step 235 

The coverage specification, at step 235, for an RFQ, is based on the line of 
10 coverage and SIC. The customer and/or advisor completes the coverage 

specifications, detailing the exact provisions of the insurance the customer wishes to 
buy. The customer/advisor is presented options within different coverage areas and 
asked to indicate what options they wish to buy. Each of these options is connected to 
a section of the coverage guide, which describes the different choices. The coverage 
15 specifications are loaded from a database of specifications specific to the customer's 
primary SIC code and the selected line of coverage. In addition to the defined options, 
the customer/advisor can add coverage provisions to the specifications. 

Each area of the coverage specifications links to coverage guide information, 
explaining why that particular aspect of coverage is important. The guide material 
20 may be developed by a third party. 

Completing certain parts of the coverage specifications may require the 
customer to provide additional exposure profiles and risk management profiles. 

Customers have the ability to input their own coverage specifications freeform 
at steps 240 and 245. The underwriters are required to respond to these items as well. 
25 At step 250, the customer can access a screen that allows the customer to 

specify different coverage options at step 255. These can be specified changes in one 
element of coverage or they can be left as freeform for the underwriter to get creative. 
These options may be related to limits, deductibles, rating programs, coverages, etc. 
At step 260, customers can select whether or not they would like to receive 
30 premium indications at varying loss levels in the quote option section. If they select 
yes, they are prompted at step 265 to enter the loss levels on which they wish to 
receive premium indications. 

At step 270, the customer can complete a coverage questionnaire. For an 
RFQ, this is based on line of coverage, SIC, and specifications. The coverage 
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questionnaire is a simple style form that provides exposure information. There are 
set of questions that apply to a coverage type on all industries, then questions that 
specific to the SIC code. Finally, there are a set of questions that are driven off the 
specific coverage requests on the specifications 
5. At step 280, the user can create an exposure profile. For an RFQ, this is based 

on the line of coverage, SIC, specifications, and coverage questionnaire. This process 
gathers underwriting data specific to the individual line of coverage. The data that 
needs to be gathered can vary by line of coverage and by industry (SIC code). The 

process then generates customized data gathering templates from a database of 
10 mdustry and line of coverage forms. The customized forms are generated based on 
the SIC codes entered in the company profile and the line of coverage from the 
coverage selector and underlying coverages selected for the RFQ. If the RFQ has been 
structured on a subsidiary basis and the subsidiary completes a company profile form 
the customized forms are generated specific to each subsidiary and based on the SIC 
1 5 code entered by that subsidiary. 

Returning to FIG. 5, the data gathered in the company profile is the overall 
descnpt,on of the company's operations and its financial statements. For publicly 
traded companies much of this data is available from public sources, such as Edgar 

^ The application contemplates integration with these systems and information reported 

20 in SEC filings. 

The information can be gathered at the subsidiary level or at the corporate 
level. The information includes general information about the company, risk 
management information, and financial information. The breakdown is shown by 
RFQ in the RFQ summary screen, or can be accessed from the secondary commands 
m the nsk profiler to go a company profile summary screen. 

hi particular, the risk management profile gathers information on an 
organization's risk management program and responsibilities. This information is 
used in the RFQ application process to provide details on how well the risk exposure 
is managed and in the risk management manual part of the Risk Assistant component 

The risk management sections can be viewed in one of two ways - either at 
random or in the RFQ view. When a RFQ is created with certain lines of coverage 
certain of these forms may need to be completed. The risk management forms axe 
specific by the line of coverage selected and the SIC code for each of the different 
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levels of corporate entity. The risk management profile information may be gathered 
at the subsidiary level. The customer administrator may also decide that it be held at 
the corporate level. 

The loss profile information includes three types of information - Loss 
5 Summaries, Large Loss Descriptions, and Loss Runs. The customer can enter an 
indefinite number of these. Loss summaries are high-level and specific for a policy 
period, providing an aggregate view of data about all individual claims. The large 
loss descriptions allow the user to view the most severe claims within a given policy 
period, where the severity is defined by the user using a threshold monetary value. 

1 0 Loss run information can be uploaded as a file attachment or fed in through the 
insurance carrier's system. The loss run information can be used to automatically 
create loss summaries that are read-only for the customer. 

Prior to submitting a RFQ into the exchange, the bid package may need to be 
approved by the customer user who is set-up with approval privileges. The approval 

1 5 process is specific to each of the forms to be included in the bid package. It can be 
performed as each of the forms are completed, or it can be completed after all forms 
have been completed. The customer may access completed forms from his/her 
desktop, review the information and click on an approval button. This action transfers 
the form from a completed status to an approved status in the customer's desktop. 
20 Once all forms have been approved the bid package can be submitted into the 
exchange. 

A submission parameters process allows the customer to define the parameters 
of the submission to the market. This includes the following elements. 

■ The lines of coverage (or RFQs) that are to be included in the submission. 
25 This may be one or many. 

■ The effective date of the coverages. 

■ The due date for quotes. This is the date by which the insurers have to get 
their quotes back to the customer. 

■ Restrictions on request for additional information. This is both the form of 
30 the request (private work room, or public forum) and the deadline for receipt 

of requests for additional information. 

■ The insurers that the customer wishes to send the submission to. The 
customers risk profile will be screened against the insurer's underwriting 
criteria. Where the risk profile meets the underwriting criteria that insurer's 
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name is included in the list of insurers to whom the submission is sent unless 
the customer deselects them. Similarly, the customer is shown a list of . 
insurers where the risk profile does not meet the insurer's underwriting 
criteria. The customer will have the option to over-ride this pre-selection and 
send a special request to the insurer to review the submission. 
Special instructions to the insurers, indicating if there are aspects of 
coverage, service or price that are particularly important. The customer can 
also have one final opportunity to attach more detailed instructions such as a 
manuscript wording. 



Multiple RFQs can be submitted at once in the build submission process; 
however, they retain their individual status as far as tracking the status of the quotes 
coming back. 

The build RFQ Process concludes by clicking a button to submit the RFQ mt0 
15 the Exchange now or submit it later. Ifthe user does not have the authority to submit 
the RFQ into the exchange, it is saved to submit later by a user with the appropriate 
authority. 



20 



25 



30 



Exchange Component - Risk Manager & Advisor 

Tne Risk Manager 1 1 and Advisor 15 can navigate the Exchange component 
120 by RFQ, In Progress RFQs, Quoted RFQs, Declined RFQs, and Archived RFQs. 
The system defaults to the summary page of RFQs, organized by RFQ folder and 
displaying the status of submissions. A summary screen displays general information 
to the customer. In addition, carrier specific information and actions can be displayed 
to the customer. A detailed quote screen displays the same information as provided 
by the insurer. It is presented in read-only format. A print-ready RFQ document can 
be prepared and a copy of the accepted quote can be placed in a policy management 
section. The detailed quote includes the following sections: 

□ Premium and rating- this includes the overall premium that the underwriter 
quoting. If this customer chooses to view premium indications at varying loss 
levels, the underwriter's input on the customer-defined loss levels is shown 
here. 

□ Specification responses - this shows the customer's specifications, the 
insurer's response for comply or not, and a comment box on each item. 



is 
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□ Other comments and information - this section allows for key quote 

differentiators, listings of exclusions and/or endorsements, attachment of files 
such as policy forms, endorsemepts, exclusions, presentations, etc. 

5 A quote summary screen summarizes received quotes to the customer. The 

customer can accept or reject the quote. The customer can also download any 
proposal or attachment that the insurer included with the quote. The customer can 
also review a summary of historical quotes provided by the insurer under this RFQ, 
allowing the customer to compare the various quotes. 
10 A reset RFQ process allows the customer to define the parameters of a second 

and subsequent round of bidding. This includes: 

■ The closing date for the round. 

■ The structure of the bidding in this round. This may be a closed bid, which is 
how the original quotes are made. Closed bids give the underwriter only" one 

1 5 opportunity to bid. Alternatively they may be open bids, in which case bids 

will be "live" for a specified period of time and the underwriter will have the 
option of amending bids during this period. 

■ Whether quote information is to be shared between the competing insurers. 
If the customer chooses to share the information, it is done on a confidential 

20 basis and detail only the highest level of quote information (i.e. that shown in 

the summary screens). 

■ A general message to all competing insurers around price, for example a 
target price. 

■ A general message to all competing insurers around services. 
25 ■ A general message to all competing insurers around coverage. 

An accept quote process allows the customer to accept a quote from the 
exchange. It may be initiated from the first or second rounds of quoting. At each of 
these stages there is an accept quote button. If this button is clicked, the system 
30 checks that the user has the authority to purchase insurance on behalf of the 

organization. If they do not, a message appears telling the user that they are not 
authorized to perform that function. If they are authorized, a screen appears 
confirming that they want to accept the quote and explaining that this sends a 
purchase order to the insurer. The customer cannot subsequently withdraw the accept 
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quote instruction. After the confirmation of the accept quote instruction, the quote is 
moved from the outstanding box in the insurer's desktop to the accepted box. An 
email notification is also sent 

Accepting a lead insurer's quote includes accepting all follow insurers for that 
quote. If the quote is not 100% supported at the time of acceptance, the acceptance is 
only be for that portion of the risk that has been quoted ("a partial quote") The 
accept quote notice is sent only to foe lead insurer, who has foe authority to bind 
coverage on behalf of the other insurers. 

Tnecustomermayrejectquotesfrom the summary quote form or the detailed 
quote form. Choosing this option communicates to the insurer that foe quote has been 
rejected. The change is reflected in foe insurer's desktop in foe quote area. In 
dechnmg a quote, foe customer should provide a reason to foe insurer for the 
declination. The reason may be chosen from a list of standard reasons or be free- 
form. The reject quote process gives immediate feedback to foe insurer that their 

quotehasbecnreject.dandthereasonwhyCprice.service.coverage). Arecordis 
thus created in foe Exchange section of the Underwriter's desktop. 

™ ec - to ™-* foe insurers can 
unual round of biddfog. During this time, foe customer may communicate with each 
msurerinaseparateworkroom. Tney may also collaborate off-line. Arecordoffoe 
on-lme discussions in the workrooms is maintained. Tie only difference to the 
collaboration around foe quote and collaboration prior to any quote is that each 
customer-insurer communication link has a unique work-room/email connection In 
foe collaboration prior to a quote, the customer may elect to use a public bulletin 
board area to receive foe requests for additional information and to post the 
25 information. 

The In Progress Function allows the customer to navigate directly to foe RFQs 
that have been put in progress by insurers, by-passing those that have yet to be 
reviewed. 

The Quoted Function allows foe customer to navigate directly to the RFQs that 
30 have received quotes from insurers, by-passing those RFQs that have not been 

renewed or are still in progress prior to a quote. The quotes section of the Exchange 

received quotes. 
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The declined section of the Exchange is where there is a log of declined 
submissions from the insurers. The declined submissions are tracked by the RFQ 
folder. 

The archive section of the site contains the details of the quotes and 
5 declinations from previous RFQs. The archived entries are shown in folder format by 
RFQ and effective date. RFQs and quotes are moved to the archive section of the 
Exchange once a quote has been rejected. This may be individually from an 
individual rejection or en bloc if an alternative quote is accepted. All quotes in an 
RFQ move to the archive section automatically after the expiration of the prior 
10 coverage. 



Exchange Component - Underwriter 

The Exchange section of the insurer's site includes a secondary level of 
commands for the Exchange component 120: Submissions, Work in Progress, Quotes, 
1 5 and Archive. The screen will default to the submissions summary page. Briefly, 

■ Submissions detail the new submissions that meet the insurers risk profile 
(Qualified) or the customer made a special request that the underwriter 
receive the RFQ submission (Special Requests). Submissions that either did 
not meet the insurer's preferences or that the customer did not specially 

20 requested the insurer are not be seen by the underwriter. 

■ Work In Progress shows a listing of all submissions that the underwriter has 
chosen to work on, but has not yet issue a quote. 

■ Quotes detail the status of the submissions that have been quoted and are still 
active. The insurer can separately link to an archive of quoted submissions. 

25 ■ Archive details inactive accounts on which the underwriter lost the bid. This 

is available for information purposes only and should not allow the 
underwriter to contact the customer. 

If a customer bundles multiple RFQs within one submission, specifically 
30 designated underwriters will be the recipient of this submission. This person can be 
referred to as a "multi-line administrator." These persons are designated by the 
underwriter administrator. The multi-line administrator can put it in progress and 
thereby make themselves responsible for reviewing the submissions and the lines of 
coverage involved and distributing them individually to the underwriters that handle 
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them. When the RFQ-specific underwriters issue their individual quotes, the multi- 
line administrator can review the individual quotes. The multi-line administrator then 
has the option to consolidate them and issue one "master quote" back to the customer 
or to submit them individually. 

5 The underwriter administrator also needs the ability to add a "cover page" on 

their "master quote" that might indicate an overall price reduction, more lines of 
coverage to come, highlights about the company, etc. The underwriter administrator 
should also be able to attach files to the "master quote." In addition, the underwriter 
administrator should be able to reassign the multi-line administrator as can be done on 
1 0 the individual quotes. 

The review submission process allows the insurer to pull the risk information 
from the customer's submission. The summary screen shows a listing of unquoted 
submissions in the market From here, the insurer can select a submission and pull 
the bid package including coverage specifications. The submission summary page 
can provide brief details of the submission, including company name, line of 
coverage, limits, retentions/attachment point, expiring premium, quote due date, and 
deadline for additional information. Once the insurer pulls the information, a 
notification can be sent to the customer that that insurer is reviewing the submission. 
The insurer's desktop then shows that the submission has moved from "New" to 
20 "Work in Progress." 

Before or after pulling the submission bformation, an insurer can elect to act 
as a "follow underwriter." By making this selection, the insurer is moved to a reserve 
pool of insurers that may be invited to join another insurer in working collaboratively 
onthequote. For an insurer indicating that they wish to follow, their desktop will 
show the submission in a "Follow - Pending" bucket. "In progress" submissions can 
be split between those that are leads and those that are follows. When an insurer 
elects to act as a follow insurer, an email notification can be sent to the customer 
infonning them of that feet 

An insurer may elect to always act as a follow market, which may be the case 
with a facultative reinsurer. This election can be made at the time that the insurer 
creates its profile. If an insurer elects to always follow, it does not see new 
submissions as a potential lead. 

Submissions are put into folders by status and by line of coverage. The 
following operations can be performed on the new submissions: 
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• Clicking on a "put in progress" button moves the selected submission to the In 
Progress folder. It also creates an entry in the customer's desktop notifying 
them that the insurer is looking at the submission. 

• Clicking on a "follow" button moves the selected submission to the Follow - 
5 Pending folder. 

• Clicking on a "decline" button takes the user to the declination screen for that 
submission. 

The link to the actual data allows the underwriter to view the submission data. 
10 Once the submission has been put in progress, the underwriter can download it Loss 
profiles and exposures schedules are downloadable as Microsoft Excel spreadsheets, 
attachments in the foimat they were attached, and the rest in Microsoft Word format 
The customer should also be able to download submission and risk information in this 
format. 

1 5 When displaying the Follow - Pending Folder, the Underwriter can exercise 

the following options: 

• Clicking on a "lead" button moves the selected submission to the in progress 
folder with the user noted as the lead insurer. It also triggers an email 
notification to the customer. 

20 • Clicking on a "remove" button takes the user to a remove submission 

confirmation screen. Once completed this moves the submission into the 
archived submissions section of the site. 

When displaying the Follow - Request for Support folder, the Underwriter can 
25 perform the following options: 

• Clicking on the accept invitation moves the submission to the In Progress 
folder and sends an email notification to the lead insurer that the invitation to 
participate has been accepted. The insurer is then removed from the pool of 
follow insurers. 

30 • Clicking on the decline button moves the submission back into the Follow- 
Pending folder and sends an email to the lead insurer that the invitation has 
been declined. The insurer remains in the pool of follow insurers. 
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When displaying the In Progress submissions folder, the Underwriter can 
perform the following options: 

• Clicking on the quote button takes the user to the quote screen. 

• Clicking on the decline button takes the user to the declination screen. 

• Clicking on the request support button takes the user to a summary screen of 
follow insurers. 

• Clicking on the workroom button takes the user to the workroom set up for 
commum'cation between the customer and the insurer for that RFQ. 



When an underwriter clicks the "put in progress" button, the system queries 
the record of who else is working on the submission. If an underwriter from the same 
company is already working on the account it informs the underwriter who else is 
working on the submission and inquires if they wish to continue. If there are no other 
underwriters working on the submission, this screen does not appear. Multiple 
1 5 underwriters from the same insurance company can work on the same RFQ and 

multiple underwriters from the same insurance company can quote on the same RFQ. 
It is up to them to coordinate their quotes. 

If an underwriter has not put a submission In Progress or Declined it within 5 
days of receiving it, then Platform Administrator should be notified via e-mail as well 
20 as through the Platform Administrator interface, which shows RFQs Without Action, 
so that offline action can be taken to contact the underwriter. 

The insurer may also appoint a follow insurer to a submission. From the In 
progress submissions folder the user may select a submission and click on the 
"Request Support" button. This takes the userto a summary of follow insurers, who ' 
25 have already been appointed to work with the underwriter on this risk. 

Clicking on the appoint follow insurer takes the user to the "appoint follow 
insurer" screen. This allows the insurer to select a follow insurer from insurers who 
have elected to follow a lead insurer rather than lead themselves. This list includes 
insurers who have elected to always follow and those insurers who have elected to 
30 follow for this particular submission. The insurer can appoint more than one follow 
insurer. A single workroom will be created for each of the lead insurers to work 
collaboratively with their follow insurers. 
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When viewing the screen to appoint a follower, the Underwriter can select the 
following options: 

• Clicking on an appoint insurer bqtton to return the user the summary of follow 
insurers screen, and sends email invitations to the follow insurers to work with 

5 the lead on this submission. The email directs the follow insurer to the 

submission summary screen in their desktop. The follow insurer can accept or 
decline the appointment by clicking on the accept or decline buttons in those 
folders. 

• Clicking on a cancel button to return the user to the summary of follow 
1 0 insurers without notifying any insurers. 

• Clicking on a research insurers button to take the user to the research section 
of the site, which allows the user to research the insurers selected. An insurer 
must be selected for the research function to work 

1 5 Each follow insurer must accept the appointment from the lead insurer. By 

doing so, they remove themselves from the pool of follow insurers for that RFQ (i.e. a 
follow insurer cannot work with more than one lead insurer). Once the appointment 
has been made, a notice can be sent to the follow insurer notifying them that they 
have been appointed as a follow insurer to work with the insurer on this submission. 
20 They are then removed from the pool of follow insurers for that risk 

From a technical insurance perspective, the lead and follow insurers are free to 
structure their own arrangement however they see fit This can be as a direct 
placement on a quota share basis, or as reinsurance of the lead insurer. 

The insurer can request more information from the customer/advisor. This is 
25 done by posting requests for additional information in the workrooms set-up by the 
customer. At the customer's option these may be public bulletin boards or 
workrooms unique to each insurer. Once the requests have been posted, a record of 
the request is created and the customer can respond through the same means 

Selecting the submission in the summary screen and clicking the workroom 
30 button takes the lead insurer to the workroom to post information with the customer. 
If the insurer is a follow insurer they are taken to the workroom for communication 
between the lead and follow insurers. This process is discussed separately in 
collaborate around a submission. 
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The insurer can also decline a quote. It may occur at any rime after the insurer 
has pulled the underwriting information and before the deadline for submitting quotes 
Declining a quote moves the submission from in progress to the archives insurer 
desktop. The process involves specifying the reason for the declination This 
5 information is provided to the customer/advisor and any re-insurers working with the 
msurer. The declinations appears against the RFQ number in the customer's desktop 
The declination process provides feedback to customers that not only will that insurer 
not be providing a quote, but the reason they will not be quoting. 

The decline risk screen js accessed Qff ^ ^ ^ ^ ^ 

can be presented with a heading detailing the customer name, line of coverage and 
RFQ Id#. It can request that the insurer provide a reason for the declination. 

Of course, the insurer can provide a quote to the customer. It requires the 
insurer to detail against the specifications whether the quote provides the coverage 
provisions requested. If it does not provide the requested provision, a text box allows 
the msurer to detail how the quote differs from the specifications. In addition to 
quoting against coverage specifications, the insurer can include: 

■ The premium; 

■ The premium at varying loss levels if the customer requests it; 

■ The reference number for the coverage form on which the policy is to be 
written (this allows comparisons from the coverage form database); 

■ The insurance company that is to be listed on the policy (this is used to 
provide carrier financial ratings); 

■ A listing of endorsements or exclusions that they are to use on the policy, and 

■ A unique message describing the insurers key differentiators for that risk' 
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The insurer may also attach a proposal, policy form, endorsements or other 
supporting information to their quote. The insurer must indicate in its quote the 
percentage of the risk that it is quoting for. It must also indicate if there are follow 
insurers involved. If so, their identity and the percentage of the risk or limit that each 
30 has quoted for. 

If the customer elects to have multiple options quoted for this policy, the 
underwriter first selects the option from the customers listing that it wishes to quote 
The underwriter completes the quote process for this option. When it finishes the 
underwriter is taken back to the customers listing of options, and then has the option 
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to quote another time. All data from the first quote is copied to the next quote and the 
underwriter can then amend the second optional quote. Other than the copying of the 
previous quote, this quote is viewed entirely separate and can have different 
attachments, etc. The optional quote is viewed separately by the customer and the 
5 only distinguishing mark is the name of the option, as defined by the customer. In a 
particular embodiment, the customer may only specify four options, therefore the 
underwriter is limited to four quotes. An underwriter is not required to issue a quote 
on an option if it prefers not to. 

It should be noted that the underwriter then responds on all the customer's 

10 specification items. All fields that require customer input rather than checkbox 
selection (such a values and dates) must be input values for the underwriter values. 
Comment boxes are available but not required regardless of compliance response. 
Customer elections by checkmark do not need to be displayed because they are the 
only items that show up for underwriter view. 

1 5 Confirming the quote and options moves the submission from the In Progress 

folder to the quotes section of the site. It also creates a record of the quote in the 
customer's side of the exchange. The user can be taken to the quote summary of the 
insurers desktop. 

A quotes screen displays a summary of all quotes that have been submitted by 
20 or on behalf of this insurer. It details high-level information with the status of the 
quote and a connection to the bind coverage process (for lead insurers only). 

When an accepted quote message appears in the insurer's desktop, the insurer 
must go into that message and specifically agree to the accepted quote message. It 
does this by clicking on the "accepted quotes" area of the desktop. 
25 This leads to a bind coverage screen that ensures that the insurer is now 

binding coverage and that this is irrevocable once issued. It also details the insurers 
and their percentage participation that the lead insurer is binding coverage on behalf 
of. 

The binder is the coverage confirmation back to the customer. Once the lead 
30 insurer issues the bind coverage notice, a binder is issued to the customer. This 

binder includes the detailed quote form and the list of participating insurers and their 
percent participation. The binder includes an electronic signature for the initial 
issuance of the binder. A hard copy with wet signature is sent in follow-up to the 
electronic binder. 
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A coverage bound confirmation is sent to each of the participating insurers 
detailmgtheirpercentparticipationandtheconfimedcoveraget^ Thisnoticeis 
put into the inbox of the policy management section of the insurer's desktop. The 
platform Administrator also receives an email notification of the binder. A hard copy 
of the binder is signed by a platform representative and mailed to the customer. 

The binder screen repeats the detailed quote form back to the customer, 
including the electronic signature from the insurer. The binder is issued as an email to 
the customer. A Microsoft Word version of the binder is placed in the workroom for 
the quote/policy. 

The archive section of the site contains the details of the quotes and 
declinations issued by that insurer from previous submissions. The archived entries 
are shown in folder format by line of coverage and customer (coded on FEIN). The 
insurer archive section follows the customer archives, with submissions and quotes 
moved to the archive section of the Exchange once a quote has been rejected. 

Communication Link Component 

The Communications Link component 130 handles all communication 
capabilities in the system, including Workrooms. A Workroom is defined by the 
participants and the action item to which it is attached. The users of this workroom 
should have the option of private or public communication (established by customer) 
and messaging or instant messaging. 

Existing communication software can be utilized for this function. The scope 
of this feature maybe governed then by the technology selected. The following 
highlights some of the basic features required of Communication Link component 
25 130. 

• Basic communication functionality such as messaging, instant messaging 
(must be stored), attachments, versioning, etc. 

• Two types of communication between the buyer and the sellers) of insurance 
- private (one buyer to one seller) and public (the buyer and all sellers). The 

30 buyer determines which type they want to use. 

• Workrooms can be created on the fly based on an action element within the 
site whether it is a RFQ, Quote, Policy, etc. 
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• Participants must be assigned to workrooms from the pool of users already 
present in our system. 

• The workrooms are only visible. and editable to those that have been assigned 
that permission. 

• All communication are stored in easily searchable archives for legal purposes. 
In particular, previously sent and "deleted" items are stored. Everything 
should be stored and referenced by its associated action element (RFQ, Quote, 
Policy, etc.). 

• . Everything is seamless to the customer. 

The Communications Link component 130 can be used in many aspects of the 
web application - from RFQ Preparation, Quote Negotiation, Policy Management, 
etc. Customers and Insurers can use this feature to collaborate and form a policy and 
agree to certain wording. The environment should be very friendly and functional. 



Risk Assistant Component 

Unlike the Exchange component 120, the Risk Assistant component 140 does 
not have a concrete sequence of steps. Instead, the Risk Assistant component 140 
includes a series of atomic actions that the Risk Manager 1 1 can take to accomplish 
20 various tasks necessary to manage their policies. The policies managed by the Risk 
Assistant component 140 can be gained using the exchange, but other policies could 
be migrated to the system to allow the Risk Manager 1 1 to centralize policy 
management 

The Risk Assistant component 140 handles policy management and 
25 certificates of insurance. The policy management process allows the customer to 
build a profile of its existing coverage, which can be used in a variety of areas of the 
site: 

■ To enable the customer to manage the issuance and accuracy of its insurance 
contracts and communicate errors or changes in risk. 

30 ■ As underlying information for RFQ bidding purposes 

■ For informational purposes in the risk management manual section of the site 

■ As the policy information for certificate of insurance issuance purposes 
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Coverages placed through the platform automatically update the policy 
manager records in the site. If someone designates a coverage as excess of other 
coverages, the system should record this and display the excess coverage on a higher 
"node" than the underlying coverage. 

When a RFQ is in progress and coverage is not yet bound, a policy record is 
shown in the Policy Management section; however, it is flagged as in progress and 
certain policy information is not yet provided. As it is bound and the carrier is 
known, the policy information is shown. 

Ideally, a coverage map is created based on the named line of coverage, 
attachment points, limits, and percent participation for the policy. Graphs and charts 
can later be created off of this information. 

Policies can also be tracked by renewal date, with notices sent to customers for 
impending renewal of their policies. Expiring policies can be moved from the 
coverage record and sent to a policy archive. 

The policy management section is a record of all policies that are currently in 
place, either with the platfoim or not, and all RFQ's that are in progress 

In addition, the customer may have changes in exposure throughout the year. 
The customer should have the opportunity, and sometimes the requirement, to notify 
the insurer about changes in their exposures. 

The customer should be able to update its risk profile throughout the year and 
then submit this data to the insurance earner of his choice and associate it with the 
appropriate policy that covers the exposure. This update of exposure info can be 
joumaled in the workroom section in that policy record within the Policy 
Management section. 

The user has the option of editing this information from this screen of the Risk 
Profiler screea If there are unapproved changes in the current risk profile, the words 
"Completed" is shown in the status column. The person with Approval authority 
approves them prior to submitting anything to the underwriter. 

The user approves the changes in risk profile in the same way that the changes 
are approved in the Risk Profiler. Once changes have been approved, a "Notify 
Underwriters of Risk Changes" button appears in the summary screen. Clicking on 
this button allows the customer to re-submit the risk profile for the policy to the 
underwriter. This is submitted in the same format as the original RFQ submission but 
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with the changes highlighted. A record of each submission is maintained and can be 
accessed from the policy management section. 

A certificate of insurance is evidence to a third party (certificate holder) that 
certain coverage is in place. The platform issues certificates of insurance on the 
5 transactions that it handles. 

Certificate of insurance issuance and management is an administratively 
difficult process and the certificates themselves do not carry any legal weight. A 
standard form has been developed by Acord for certificates and has become an 
accepted standard in the industry. However, several customers have developed their 
10 own forms and processes to minimize the administrative burden of issuing 
certificates. 

The system does not use the Acord standard form. It will issue a general email 
notification that contains the information that the certificate holder needs to verify that 
coverage is in place and that they have the appropriate coverage. 

1 5 The certificate of insurance system obtains from the customer/advisor a listing 

of all parties that are to receive email notifications (certificates) and the parameters of 
the notification. Emails will be generated to those certificate holders with specific 
information to suit their requirement parameters. All of this data is pulled from a 
database that houses the information on the transaction that supports the insurance 

20 policy. 

The platform is notified by insurance carriers when they are canceling or non- 
renewing insurance policies. The platform then generates emails to all the certificate 
holders (and the insured) on that policy, notifying them of the pending cancellation. 
The system can also integrate with a certificate tracking system. A certificate 

25 tracking system tracks, for a certificate holder, all certificates received by certificate 
issuers. In doing this, certificate holders establish an account with the platform and 
provide an account number to them. They then distribute this account number to their 
business partners (our customers that are certificate issuers). The customer can then 
just enter the certificate holder number when prompted for new certificate holder. 

30 When the certificate holder logs in, they see a listing of companies providing 

them certificates and the expiration dates of those coverages. Then they can drill 
down to actually view the individual certificates and print a copy, if desired. The 
platform can provide a link for them to contact the customer so that they can 
communicate about their requirements or follow up for renewal certificates. 
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Advisor Assistant Component 

The Advisor Assistant component 143 provides a suite of tools to allow 
advisors to manage their client's account information and work on their client's behalf. 
5 The system allows the use of multiple advisors working on the client's account and 
interaction amongst them. 

Underwriting Assistant Component 

The Underwriting Assistant component 146 includes functions for policy 
10 management The insurer's policy management section follows a similar structure to 
the customer's Risk Assistant 140. A unique policy record is created as soon as the 
insurer clicks on the bind coverage button. In contrast with the customer, only 
platform policies are displayed in this listing. 

The policy management tools mirror the customer side, with collaboration 
tools and the ability to see the customer designated status as Not Received/ Received- 
Not Reviewed/ Reviewed-Major Issues/ Reviewed-Minor Issues/ Complete. This 
allows the underwriter to see the customer/advisor assessment of where the policy 
stands. The insurer can also specify which policy is to be cancelled and indicate the 
number of days until cancellation. 
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Research Tools Component 

The Research Tools component 1 50 allows the customer to research the 
insurers on aspect of the quote beyond that detailed within the quote form. The 
research may be accessed from the quote form summary or separately from other 
25 areas of the site. The research tools include the following: 

■ Descriptive information on the company. This can be standard promotional 
information provided from the insurer. If available, third party profile 
information can also be provided. For example, AM Best or Standard & 
Poors profile information on the insurer group and each of the specific 
insurers participating in the exchange. This information will be shown in 
HTML format 
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■ Descriptive information on the key features of the insurer's products for that 
line of coverage. This marketing information can be provided by the insurer 
and shown in HTML format. 

■ Service standards for the insurer. This can follow a standard template 

5 provided by the platform. It serves to detail the services that the customer can 

expect to receive from the insurer. 

■ RIMS scorecard information. This can be accessible from a database 
searchable by insurer name and performance driver. The platform gathers 
this information on an on-going basis* 

10 ■ Financial rating information from AM Best, Standard & Poors and Moodys. 

This information can be provided in the site within a searchable database. 

Links to specific insurers' web sites can be provided from the descriptive 
information on the insurer and the marketing information of its insurance products. 

15 

Administration Component 

The Administration component 160 handles administrative duties for the 
platform 10. These duties include registration of new insurance companies. New 
users can also be added to the system and existing users suspended from using the 
20 system. The Administration component 1 60 can also be used to query data to obtain 
custom reports for customers and insurers. 

Support Component 

The Support component 1 70 provides methods for users of the system to 
25 obtain assistance from Global Risk Exchange personnel in all facets of using the 

application. Support can be provided in messaging, interactive instant messaging, and 
telephone support 

Account Information Component 
30 The Account Information component 1 80 allows users of the system to obtain 

information about their account and supply updated user information. 



Client Information Component 
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The Client Information component 1 85 stores the client contacts for each 
Advisor 15. Each client record can be linked to that client's account for access by the 
Advisor 15. In addition, former clients can be displayed so the Advisor 15 can review 
correspondence with that client 

News Portal Component 

The News Portal component 190 allows the Risk Managers 1 1 and Advisors 
15 to access external sources of information. The portal can include a web browser. 

Given the details of the platform 1 0, the risk lifecycle shown in FIG. 3 can 
be further described FIGs. 7-10 illustrate the interactions between the parties and 
the platform 10 during operation of the Risk Profiler 1 10 and Exchange 120 
components of FIG. 5. 

FIG. 7 is a schematic block diagram illustrating interactions for the risk 
profiling, risk assessment, and program design steps of FIG. 3. Precursors for these 
interactions include accounts set up for the Risk Manager customer 11 , the Advisor 
15, and the Insurer 19. 

Offline, the Risk Manager 1 1 forwards a marketing agreement a step 300 to 
the support facility 12. The support facility 12 then places the agreement online to 
the platform 10 at step 302. The Risk Manager 1 1 then goes online at step 310 to 
use the Risk Profiler component 110 (FIG. 5) to enter the customer's risk profile, 
including underwriting data, coverage data, and corporate data. Some of this date 
may be supplied by the Advisor 15 at step 312 and by the support facility 12 at step 
314. 

The Risk Manager 1 1 and the Advisor 15 collaborate at step 320 on risk 
assessment and program design. This collaboration can include on-site meetings, 
tours, etc. As such, this collaboration is generally handled offline. But online 
facilities such as Workrooms can also be used, where convenient At step 330, the 
Advisor 15 goes online to further facilitate the program design in support of the 
Risk Manager 1 1 . These operations may require technical support from the support 
facility 12, either online support (step 340) or offline support (step 350). 

Data collection begins at step 360, where hard copy information is sent 
offline from the Risk Manager 1 1 to the support facility 12. Offline data collection 
from third parties 1 8, such as Edgar, is shown at step 370 being feed to the support 
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facility 12. An online data feed between the third party 18 and the platform 10 is 
shown at step 372. 

Finally, at step 380, the Risk Manager 1 1 approves the Risk Data. 
FIG. 8 is a schematic block diagram illustrating interactions for. the complete 
5 and send RFQ steps of FIG. 3. At step 410, the Risk Manager 1 1 goes online to set 
rules for bidding for the risk transfer. The Advisor 1 5 may assist in that process at 
step 412. At step 420, the platform 10 returns to the Risk Manager 1 1 a list of 
available underwriters that match the bidding rules. The Advisor 1 5 may also 
affect the listed underwriters, as shown at step 422 
10 At step 430, the Risk Manager 1 1 selects Underwriters 19 from the list and 

submits the RFQ to the market. The Advisor 15 can assist the Risk Manager 1 1 or 
select the Underwriters 19, as shown at step 432. 

At this point, the support facility does "Market Making." This includes an 
online process between the support facility 12 and the platform 10, as shown at step 
1 5 440. It can also include an online interaction between the platform 1 0 and the 
Underwriters 19 at step 442. It can further include offline collaboration between 
the support facility 12 and the Underwriters 19 at step 444. 

At step 450, the RFQ is sent from the platform 10 to the Underwriters 19. 
At step 460, the Risk Manager 1 1 forwards binders offline to the Underwriters 1 9. 
20 FIG. 9 is a schematic block diagram illustrating the collaboration and 

negotiation steps of FIG. 3. At step 510, the Underwriter 19 reviews the RFQ 
online. At step 520, an Underwriter 19 can request addition information from the 
platform 10. An Underwriter 19 can also request information from and otherwise 
collaborate with the Risk Manager 1 1 offline, as shown at step 522. The way to 
25 provide the additional information is unstructured. The Risk Manager 1 1 can enter 
information online into the platform 10 (step 530), offline to the Underwriter 19 
through the support facility 12 (steps 532, 534). In addition, the Risk Manager 1 1 
" can review information derived offline from the Underwriter 19 at step 536. 

The result is an offered quote into the platform at step 540. The quote can 
30 be a structured or an unstructured response. Steps 550 and 552 illustrate facultative 
reinsurance via online and offline communications, respectively. At steps 560 and 
562, the Risk Manager 1 1 and Underwriter 19 enter n-rounds of negotiations on the 
coverage and quote. 
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FIG. 10 is a schematic block diagram illustrating the bind, issue, and store 
steps of FIG. 3. After the quotes and coverages are negotiated, the Risk Manager 
1 1 compares the quotes and coverages from the submitting Underwriters 19. This 
can include an online review of the quotes (step 610) and offline collaboration with 
the Advisor 15 (step 612). 

Assuming a suitable quote is obtained, the Risk Manager 1 1 accepts the 
quote online at step 620. The acceptance causes the platform 10 to notify the 
selected Underwriter 19 at step 630. 

A binding process then occurs to bind the parties to the policy. The 
Underwriter 19 initiates the binding process at step 640, where a binding instruction 
is sent to the platform 10. The platform in rum issues a binding notification to the 
Risk Manager 1 1 at step 642. The support facility 12 also receives an online 
binding notification from the platform 10 at step 644, an offline binding notification 
from the Underwriter 19 at step 646, and an offline binding notification from the 
Risk Manager 1 1 at step 648. If the bindings are in order, the support facility 
confirms the bindings at step 644. An offline paper binding may also be sent from 
the Underwriter 1 9 to the Risk Manager 1 1 at step 649. 

A policy is then issued from the Underwriter 19 and the Risk Manager 1 1 to 
the platform 10 at steps 650 and 652, respectively. Additional policy language 
negotiations may occur offline between the Risk Manager 1 1 and the Underwriter 
19 at step 660. This negotiation may also involve the Advisor 15 at step 662. The 
resulting policy is then stored on the platform 10 at step 670. 

Unlike the operation of the Exchange component 120, the Risk Assistant 
component 1 40 can perform non-linear functions. The interactions of the parties 
during operation of the Risk Assistant component 140 (FIG. 5) are shown in FIGs. 



11-17. 



For example, the Risk Assistant component 140 allows the Risk Manager 1 1 
to issue certificates directly to a user via email. This removes the broker from the 
process, and allows the Risk Manager 1 1 to perform this day-to-day task quickly 
30 and directly. 

FIG. 1 1 is a schematic block diagram illustrating interactions for issuing and 
distributing a certificate. At step 710, the Risk Manager 1 1 sets up system 
parameters online with the platform 10. At step 720, a Certificate Holder 20 can 
request a certificate from the Risk Manager 1 1 via an offline communication. The 
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Certificate Holder 208 can alternatively access the system directly at step 722 to 
request the certificate. 

In response to the request, the Rjsk Manager 1 1 at step 730 inputs detailed 
information about the Certificate Holder 20 into the system. The system then 
5 queries to determine if the Risk Manager 1 1 has coverage and validates the system 
parameters. If everything is in order, the system issues a certificate directly to the 
Certificate Holder 20, either online via email (step 740) or offline via facsimile or 
mail (step 742). Alternatively, the support facility 12 can transmit the certificate to 
the Certificate Holder 20 via facsimile or mail, at step 744. 
10 The system may throw an exception to the Risk Manager 1 1 at step 750. In 

response, the Risk Manager 1 1 , at step 760, can override parameters. The Risk 
Manager 1 1 can then, at step 770, grant access to the Certificate Holder 20. At step 
780, the system sends access information to the Certificate Holder 20. 

Finally, at step 790, the Underwriter 19 can query and view information 
1 5 about the Certificate Holder 20. 

Similarly, the Risk Manager can use the system to generate automobile 
identification cards without having to use the broker. 

FIG. 12 is a schematic block diagram illustrating interactions for generating 
automobile identification cards. At step 810, the Risk Manager 1 1 queries the 
20 system to obtain a list of vehicles against which there is coverage. At step 820, the 
Risk Manager 1 1 selects the vehicle desired for printing of the identification card. 

The Risk Manager 1 1 can also use the Risk Assistant component's 140 
policy management functionality to change and update existing policies. 

FIG. 1 3 is a schematic block diagram illustrating interactions for policy 
25 management functions. At step 910, the Risk Manager 1 1 can view a policy online. 

The Risk Manager 1 1 then goes into the Risk Profiler component 110 and 
initiates a Request for Change (RFC) at step 920. The system tracks the change 
history and creates audit trails. At step 930, information for the change is submitted 
to the appropriate Underwriter 1 9. The Underwriter may choose to do nothing or 
30 go into collaboration. The system provides an online collaboration environment 
(steps 940, 942, 944) to negotiate the changes to the policy. There can also be 
offline collaboration (steps 946, 948). 

The Risk Manager 1 1 can also submit first reports of loss directly to the 
Underwriter 19 using the Risk Assistant component 140. The platform 10 
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maintains the data, and will have the loss information available for loss runs and 
foture requests for quotes. The advantage in this mode, is that the report of loss can 
be managed centrally through the system. 

FIG. 14 is a schematic block diagram illustrating interactions for a claim of 
firstreportoflos, Atstep 1010, the Risk Manager 11 selects a policy and form 
onlme, and fills out the form online. The claim can be transmitted to the insurer's ^ 
clanns department 29, either through direct intention or email (step 1 020) or via 
facsnnile or mail (step 1022). At step ,030, state forms can be transmitted online 

^ ArectlytothestateagencySO. Alternatively, the paper forms can be filled out and 
IV faxed to the state agency 30 at step ,032. 

" add *°n.theRiskM^^ 
Risk Assistant component 140. 

FIG. 15 is a schematic block diagram illustrating interactions for loss run 
reportmg. As shown, the system includes connections to aggregators and insurance 
companies in order to provide accurate and rich data. 

A Risk Manager supervisor „' with the ^msfe security , eve , m ^ & 
request for information to the insurance company 25 either electronically through 
^^C^110fl.ll02)orvi.. m <^^ ( ^ 1104Xtol ^ totte 
request, at step 1,10, the insurance company sends data to the platform , 0 for 
20 customers that they insure. 

The Risk Manager supervisor 1 , >, at step , 1 20, can then run a report on its 
ownrnformation. As shown at step ,122, the Advisor 15 canassist in running the 
report The Risk Manager supervisor 11 > and Advisor 1 Scan prepare online 
benchmarking or other ana,ytics at steps 1 130 and 1 132, respectively. The system 
25 then runs aggregation reports. 

The Risk Assistant component 140 can also provide several functions listed 
below to allow the Risk Manager 1 1 to further manage the policy online through the 
system. An issue policy function can operate the same as in the Exchange component 
120, but wrth data pre-population. The Risk Assistant component 1 40 can also 
determine whether to renew or rebid a policy. Tnis is the same process as in the 
Exchange component 120, except that there are pre-expiration notifications and 
renunders. ,n addition, the Risk Profile is update throughout the year to validate the 
mformation in the RFQ and to send the RFQ. The Risk Assistant component 140 can 
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also facilitate online risk management functions, such as the viewing of coverage 
information, policy information, profile information, and additional content 

The system can also support facultative reinsurance. In particular, two models 
will be described: Lead and Follow, and Subscription. 
5 FIG. 1 6 is a schematic block diagram illustrating interactions in a lead and 

follow model for facultative reinsurance. This model allows an underwriter to 
assemble 100% coverage of a given risk from coverage supplied by his company and 
other insurance companies. 

At step 1210, the Risk Manager submits an online RFQ. At step 1220, a first 
10 Underwriter 1 9-1 receives the RFQ but does not want to bear the entire risk. At step 
1 230, the first Underwriter 1 9-1 queries for a "follow" underwriter. The result of that 
search is a second Underwriter 19-2. 

The two Underwriters 19-1, 19-2 collaborate through either a Workroom 
(steps 1240, 1242) or offline (step 1244). The collaboration results in the an 
1 5 agreement between the Underwriters 1 9- 1 , 1 9-2 to together bear 1 00% of the risk. 
The first "lead" Underwriter 19-1 responds to the RFQ with a quote for 100% of the 
coverage at step 1250. At step 1252, the quote is transmitted to the Risk Manager 1 1 
for review. At step 1260, the Risk Manager 1 1 can accept the quote. 

FIG. 1 7 is a schematic block diagram illustrating interactions in a subscription 
20 model for facultative reinsurance. This model places the onus of assembling 100% of 
the policy coverage on the Risk Manager 1 1 and Advisors 1 5. Individual insurance 
companies bid on portions of the total risk, and the Risk Manager 1 1 works with the 
Underwriters 1 9 to complete the coverage. 

At step 1310, the Risk Manager 1 1 submits an online RFQ for coverage of 
25 100% of the risk. A first Underwriter 19-1 receives the RFQ at step 1320. The first 
Underwriter 1 9-1 responds with a quote for 40% of the risk, at step 1 330. At step 
1332, the Risk Manager 1 1 receives the quote for review. At step 1 340, the Risk 
Manager 1 1 accepts the terms and conditions for the 40% quote, conditioned on 
accepting a quote for the remaining 60% of the risk. 
30 At step 1 350, the Risk Manager 1 1 resubmits the RFQ seeking support for 

the remaining 60% of the risk. The Risk Manager 1 1 can choose the market to send 
the RFQ to. At steps 1360 and 1362, a second Underwriter 19-2 and a third 
Underwriter 1 9-3, respectively, receive the RFQ. After considering the RFQ, the 
second and third Underwriters 19-2, 19-3 decide to accept some risk. All three 
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Underwriters 19-1, 19-2, 19-3 then collaborate in an online Workroom at step 1370. 
After collaborating, at step 1380 and 1382, the second and third Underwriters 19-2, 
19-3, respectively, submit an online quote for the remaining 60% of the risk. The 
two quotes are received by the Risk Manager 1 1, at step 1384, for review. At step 
5 1390, the Risk Manager 1 1 can accept the aggregate 100% coverage. 

Those of ordinary skill in the art should recognize that methods involved in a 
system for managing risk transactions may be embodied in a computer program 
product that includes a computer usable medium. For example, such a computer 
usable medium can include a readable memory device, such as a solid state memory 
device, a hard drive device, a CD-ROM, a DVD-ROM, or a computer diskette, having 
computer readable program code segments stored thereon. The computer readable 
medium can also include a communications or transmission medium, such as a bus or 
a communications link, either optical, wired, or wireless, having program code 
segments carried thereon as digital or analog data signals. 
15 While the system has been particularly shown and described with references to 

particular embodiments thereof, it will be understood by those skilled in the art that 
various changes in form and details may be made therein without departing from the 
scope of the invention encompassed by the appended claims. For example, the 
methods of the invention can be applied to various environments, and are not limited 
20 to the environment described herein. 
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CLAIMS 

What is claimed is: 

1 . A system for managing a risk transaction, comprising: 

a customer interface to a risk exchange platform, the customer 
interface facilitating the creation of a request for quote for transferring at least 
a portion of a risk from the customer to a risk market. 



1 0 2. The system of Claim 1 wherein the customer interface further facilitates the 
building of a risk profile. 

3. The system of Claim I wherein the customer interface further facilitates 
receiving a quote from a risk bearer. 

15 

4. The system of Claim 3 wherein the customer interface further facilitates 
negotiation between the customer and the risk bearer. 

5. The system of Claim 4 wherein the customer interface can access a computer- 
20 based work environment for the negotiation. 

6. The system of Claim 1 wherein the customer interface can access a computer- 
based work environment to facilitate collaboration between the customer and 
another party. 

25 

7. The system of Claim 6 wherein the other party is an advisor assisting the 
customer. 

8. The system of Claim 6 wherein the other party is a risk bearer. 

30 

9. The system of Claim 6 wherein the other party is a support facility of the risk 
exchange platform. 
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10. The system of Claim 1 wherein the customer interface facilitates an integrated 
management of risk products for the customer. 

»• The system of Claim 1 wherein the customer is represented by a plurality of 
5 users each user having a respective customer interface. 

12. The system of Claim 1 wherein each user is assigned a respective access right 
from a plurality of access rights. 

10 13. A system for managing risk transactions, comprising: 

a database having stored therein risk data from a plurality of customers 
and a plurality of risk bearers; 

a first interface for exchanging risk data with a customer; and 
3 SeC ° nd hterface for ^changing risk data with a risk bearer. 

14. The system of Claim 13 wherein the risk data includes data representing a risk 
profile from a customer. 

15. ^e system of Qaim 13 wh^^ 
M re q^st for quote from a customer. 

16. The system of Claim 13 wherein the risk data includes data representing an 
insurance quote from a risk bearer. 

25 17. The system of Claim 1 3 wherein the risk data includes data representing an 
insurance policy between a customer and a risk bearer. 

18. The system ofCIaim 13 further comprising a third interface for exchanging 
risk data with an advisor representing a customer 

30 

19- The system of Claim 13 further comprising an online collaboration facility 
usable by a customer and a risk bearer. 
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20. The system Claim 1 3 wherein the risk data includes data representing a 
reinsurance agreement between a plurality of risk bearers and a customer. 

2 1 . The system of Claim 1 3 wherein the risk data includes a dynamic product 
5 definition and dynamic pricing of a risk product 

22. The system of Claim 1 3 wherein the database is coupled to a server computer 
on a computer network. 

10 23. The system of Claim 13 wherein the customer is represented by a plurality of 
users, each user having a respective first interface. 

24. The system of Claim 23 wherein each user is assigned a respective access 
right selected from a plurality of access rights. 

15 

25. The system of Claim 13 wherein the risk bearer is represented by a plurality of 
users, each user having a respective second interface. 

26. The system of Claim 25 wherein each user is assigned a respective access 
20 right selected from a plurality of access rights. 

27. The system of Claim 13 further comprising a data interface to an external data 
collector. } 

25 28. A method for managing a risk transaction, comprising: 

coupling a customer interface to a risk exchange platform; and 
from the customer interface, facilitating the creation of a request for 

quote for transferring at least a portion of a risk from the customer to a risk 

market. 

30 

29. The method of Claim 28 further comprising, from the customer interface, 
facilitating the building of a risk profile. 
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30. The method of Claim 28 further uprising, fron, the ouster interface 
facihtating the receipt of a quote from a risk bearer. 

fachtanng negotiation between the customer and the risk bearer. 

32. The method of Claim 31 further comprising, from the customer interface 
accessing a computer-based work environment for the negotiation. ' 

accessmg a computer-based work environment to facilitate collaboration 
between the customer and another party. 

13 customer. 5 



35. The method of Claim 33 wherein the other party is 



a risk bearer. 



^ u nsk exchange platform. 

37. ^^rfChtaM^a.^^^^^ 
facihtatang an integrated management of risk products for the customer. 

users, each user having a respective customer interface. 

39. n-^rfOd»3«il^eao^ ai ^^ WlB ^ 
access right from a plurality of access rights. 



30 

40. 



A method for managing risk transactions, comprising: 

storing risk data from a plurality of customers and a plurahty of risk 
bearers in a database; 

changing risk data with a customer through a first interface; and 
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exchanging risk data with a risk bearer through a second interface. 

4 1 . The method of Claim 40 wherein the risk data includes data representing a risk 
profile from a customer. 

5 

42. The method of Claim 40 wherein the risk data includes data representing a 
request for quote from a customer. 

43. The method of Claim 40 wherein the risk data includes data representing an 
10 insurance quote from a risk bearer. 

44. The method of Claim 40 wherein the risk data includes data representing an 
insurance policy between a customer and a risk bearer. 

1 5 45. The method of Claim 40 further comprising exchanging risk data with an 
advisor representing a customer through a third interface. 

46. The method of Claim 40 further comprising coupling an online collaboration 
facility between a customer and a risk bearer. 

20 

47. The method Claim 40 wherein the risk data includes data representing a 
reinsurance agreement between a plurality of risk bearers and a customer. 

48. The method of Claim 40 wherein the risk data includes a dynamic product 
25 definition and dynamic pricing of a risk product. 

49. The method of Claim 40 further comprising coupling the database to a server 
computer on a computer network. 

30 50. The method of Claim 40 wherein the customer is represented by a plurality of 
users, each user having a respective first interface. 

51. The method of Claim 50 further comprising assigning a respective access right 
to each user, selected from a plurality of access rights. 
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52. The method of Claim 40 wherein the risk bearer is represented by a plurality 
of users, each user having a respective second interface. 

5 53. Method of Claim 52 firr^^ 

to each user, selected from a plurality of access rights. 

54. The method of Claim 40 further comprising coupling an external data 
collector to the database using a data interface. 
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55. An article of manufacture, comprising: 
a computer usable medium; and 

a set of program instructions carried on the medium for managing a 
nsk transaction, including instructions for 

coupling a customer interface to a risk exchange platform; and 
from the customer interface, facilitating the creation of a 
request for quote for transferring at least a portion of a risk from the 
customer to a risk market. 



20 



56. An article of manufacturing, comprising: 
a computer usable medium; and 

a set of program instructions carried on the medium for managing a 
risk transaction, including instructions fon 

Storing risk from a plurality of customers and a plurality of 
risk bearers in a database; 

exchanging risk data with a customer through a first interface; 

and 

"changing risk data with a risk bearer through a second 
30 interface. 
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